11. 인터넷 구조를 알아보자

38. 인터넷 구조

인터넷은 LAN, ISP, 모바일 네트워크 등을 연결하는 광범위한 네트워크임. 라우터의 역할이 크며 패킷을 지정된 대상에 전달해서 통신하게 됨.

인터넷의 기원: 1967년 ARPANET 계획에서 진행한 패킷 통신망 연구에서 시작되었으며, TCP/IP 개발도 이 연구의 성과 중 하나임.

네트워크를 연결하는 인터넷 구조

라우터는 인터넷을 구성하는 요소 중에서도 중요한 역할을 하며, 패킷의 교통정리를 담당함.

LAN 내부 통신은 외부로 내보내지 않음.
자신의 LAN 주소가 아닌 통신은 내부로 들여보내지 않음.
자신의 LAN 주소가 아닌 통신은 라우팅 테이블이나 기본 게이트웨이를 설정하여 전달됨. 이때 IP 주소를 자신이나 자신이 관리하는 LAN, 전송 대상의 식별자로 사용함.

인터넷에서는 모든 패킷이 라우터를 이용하여 버킷 릴레이처럼 운반됨. 각 라우터는 라우팅 테이블의 범위만큼 연결 정보를 가지고 있는데, 이 기능 덕분에 패킷이 올바른 목적지로 전달됨.

39. 인터넷에서 사용하는 프로토콜

기본적으로는 TCP/IP지만 이를 기반으로 하는 다양한 프로토콜이 있음.

TCP/IP는 IP 주소를 기반으로 패킷을 전송하는 기능밖에 없음. 오류 검사나 세션을 확립하는 기능은 있지만, 목적지에 패킷이 도달했는지, 재전송할 필요가 있는지 확인하는 역할은 애플리케이션의 몫임. 이것만으로는 이메일 교환 등 복잡한 기능을 실현하기는 어려움.

서비스 프로토콜로 상위 기능 실현

라우팅 정보를 교환하고 패킷을 효율적으로 전달하는 프로토콜 외에도 파일 전송, 암호화 통신 등 다양한 상위 프로토콜과 서비스 프로토콜이 있음. 여러 개의 서비스 프로토콜을 사용하기도 함.
서비스 프로토콜은 다양한 웹 앱, 서비스 등을 구현하는 데 필수적임. 대부분의 웰노운 포트는 서비스 프로토콜에 할당되어 있음. 서비스 프로토콜과 포트 번호는 IANA에서 할당을 관리함.
예시: DNS, SMTP (이메일 전송), IMAP/POP (이메일 수신), FTP (파일 전송), SSH (원격 접속) 등

40. 이메일을 주고받는 구조

인터넷상에서는 SMTP나 POP를 이용하여 이메일을 송수신함.

이메일을 보내려면 받는 사람의 주소를 지정하여 자사에서 관리하는 메일 서버로 전송함. 송신 메일 서버는 이메일 주소의 도메인 이름을 확인해서 받는 사람의 수신 메일 서버로 전송함.
수신 메일 서버는 POP 프로토콜로 수신함. 올바른 수신자에게 이메일을 전달하기 위해 사용자 데이터베이스가 있음. 이메일을 받으면 각 사용자 ID에 해당하는 스풀 파일에 이메일 본문을 저장함. 메일 클라이언트가 POP 서버에 접속해서 정상 사용자로 인증되면 이메일을 내려받음. 이메일은 스풀 파일에서 삭제됨. IMAP은 스풀 파일에서 이메일이 삭제되지 않음.

💡 주요 용어

스풀 파일: 나중에 처리하려고 일시적으로 서버에 저장되는 파일.

메일 프로토콜 보안: 대부분 보안 기능이 없으므로, SMTP로 전송하기 전에 발신자 인증이나 암호화 등 프로토콜을 확장하거나 추가해야 함.

41. 웹페이지를 열람할 수 있는 구조

웹을 구성하는 인프라 기술에는 TCP/IP, HTTPS, DNS 등이 있음. 웹은 웹 서버, 클라이언트, HTML, Java, SQL, XML, REST API 등으로 구성됨.

웹의 구조는 확장성을 고려해서 동영상이나 음성 등도 통합할 수 있는 데이터 형식으로 HTML이 채택됨. HTML 형식의 문서를 웹 서버에 저장하고 웹 클라이언트(크롬 등)가 인터넷을 통해 웹 서버에 액세스하여 페이지를 화면에 표시하는 방식임. 현재는 Nginx, Apache 등이 주로 사용됨.

HTTPS의 보안: 페이로드를 암호화해서 전송함.

42. URL / URI

URL은 네트워크나 서버 등을 식별하는 역할을 함. 네트워크나 서버 지정에는 도메인 이름을 사용하고, 프로토콜로는 HTTP/HTTPS를 사용함.

URL: 인터넷상의 서버나 데이터 등을 특정하는 방법. 리소스의 보관 위치를 나타냄.
URI/URN: 각각의 리소스 위치와 이름을 기술하는 방법임.

인터넷상의 위치란 어느 네트워크, 어느 서버의 특정 파일인가 하는 정보임. 이용하는 프로토콜이나 임의의 값을 가지는 변수도 지정 가능함. 서버를 지정하려면 일반적으로 도메인 이름을 사용함. 프로토콜에는 HTTP, HTTPS, FILE, DATA 등이 예약어로 등록되어 있음.

구성 요소

스키마: 장소에 액세스하는 프로토콜을 지정함.
권한: //로 시작하고 장소를 다음 요소로 지정함.
- 사용자 정보: 사용자 ID 및 계정 등.
- 호스트 정보: 서버의 도메인 이름.
- 포트 정보: 액세스할 포트 번호.
경로: 서버의 파일 경로를 /로 구분하여 지정함.
쿼리: ? 이후의 문자열을 변수 또는 명령으로 지정함. 액티브와 패시브 두 종류의 파라미터가 있음.
프래그먼트: 서버의 응답이나 부호로서 웹 브라우저가 처리하는 정보. 앵커라고도 함.

예시 1: https://user1:pass1@aa.bbb.kr:8080/abc/def.html?z=p1#p2

스키마: https
권한: user1:pass1@aa.bbb.kr:8080
경로: /abc/def.html
쿼리: z=p1
프래그먼트: p2

예시 2: https://www.aaa.bbb.kr/abc/def.html?color=blue

스키마: https
호스트 정보: www.aaa.bbb.kr
경로(파일): /abc/def.html
쿼리: color=blue

&으로 다수의 파라미터를 부여할 수도 있음. FILE을 지정하면 권한 부분의 기술은 로컬 호스트가 되고, 경로는 해당 컴퓨터가 됨.

43. HTTP/HTTPS

웹에서는 HTTP/HTTPS 프로토콜을 사용해서 정보를 교환함. HTTP의 보안을 강화하고 패킷 페이로드를 암호화하여 상호작용하는 프로토콜이 HTTPS임.

일반적인 프로세스는 웹 브라우저가 웹 서버에 페이지를 요청하는 것이 먼저임. 요청 정보는 URL로 기술되며, 요청받은 서버는 해당하는 HTML 파일을 반환하면서 응답함.

HTTP는 하위 프로토콜로 TCP를 사용하여 세션을 설정함. 하지만 웹 브라우저 및 웹 서버의 요청과 응답은 전후 통신에 관계없이 매번 독립적으로 처리됨. 이런 통신을 stateless라고 함. 이 통신에서는 각각의 통신이 독립적이고 의존성이 없으므로 같은 페이지를 여러 번 반복해서 요청해도 매번 같은 HTML이 전송됨. stateless 통신인 이유는 웹 서버가 불특정 다수의 브라우저 요청을 처리하는 동안 상태를 유지하는 것이 어렵기 때문임. 다만 일반적으로 웹 브라우저는 캐시 기능이 있어 한번 접속한 웹페이지 정보를 보관하고 있다가 저장된 파일을 사용하여 서버 접속을 회피함.

주요 개념

HTTPS: HTTPS에 SSL/TLS라는 암호화 프로토콜을 조합해서 보안 통신을 하는 프로토콜임.
Cookie: 쿠키를 사용하여 스테이트풀(stateful) 기능을 구현할 수 있음. 쿠키라는 작업 파일을 과거 방문한 웹페이지의 URL과 타임스탬프, 세션 정보, 주소 및 이메일 주소 등을 사용자 컴퓨터에 저장할 수 있음. 웹사이트 방문자를 추적하고 분석하기 위해 웹 서버에서 쿠키 정보를 활용할 수 있음.

44. DNS

도메인 이름과 IP 주소의 대응표를 관리하는 체계임. 이 대응표 데이터베이스를 관리하는 서버를 DNS 서버라고 하며, 여러 서버에 데이터베이스를 분산함.

인간이 다루기 쉬운 이름으로 인터넷을 이용할 수 있도록 고안된 것이 도메인 이름이고, 이를 관리하기 위한 것이 DNS임. 도메인 이름은 조직별 서버 이름에 지역, 속성 등 정보를 계층적으로 추가한 것임. URL의 권한 부분에서도 사용되는 표기 방법임.

DNS 데이터베이스에서는 일반적으로 도메인 이름과 IP 주소가 **영역(zone)**이라는 단위로 관리되며, 서버 간에 서로 통신하여 데이터베이스 내용을 교환함. 이 영역 정보를 유지하는 서버를 권한 DNS 서버 또는 네임서버라고 함.

DNS에서는 클라이언트에서 IP 주소 문의가 있을 때 LAN 내 DNS 서버가 도메인 이름을 알고 있다면 IP 주소를 직접 알려주고(내부 도메인 서버), 모른다면 다른 DNS 서버에 문의함. 이 문의를 처리하는 프로그램을 **리졸버(resolver)**라고 함. 리졸버는 DNS 서버에 포함될 수도 있지만, 컴퓨터나 기기 쪽에서 문의만 처리하는 **스텁 리졸버(stub resolver)**도 있음.

주요 용어

권한 DNS 서버: 영역 내 호스트 정보를 직접 관리하는 서버. DNS 서버는 권한 있는 DNS 서버에서 정보를 받고, 권한 있는 DNS 서버가 스텁 리졸버에 응답함.
스텁 리졸버 (Stub Resolver):
스텁 리졸버는 DNS 조회를 요청하는 클라이언트(예: 개인 PC, 스마트폰)에 내장된 가장 기본적인 형태의 DNS 클라이언트임. 이름 그대로 '스텁(stub, 남은 부분)'처럼 최소한의 기능만 수행함.
- 역할: IP 주소를 직접 찾지 않고, 설정된 DNS 서버(주로 통신사에서 제공하는 재귀적 리졸버)에게 "www.example.com의 IP 주소가 뭐야?"라고 물어보는 역할만 수행.
- 동작 방식: 질문을 보내고, 최종적인 답변(IP 주소 또는 에러 메시지)이 올 때까지 기다리기만 함. 복잡한 과정은 모두 상위 DNS 서버에 위임.
- 관계: 클라이언트 PC (스텁 리졸버) <--> 재귀적 DNS 서버 <--> 루트/권한 DNS 서버 와 같은 구조로 동작하여, 클라이언트는 복잡한 DNS 조회 과정 없이 간단하게 IP 주소를 얻을 수 있음.

45. ICMP

목적지와 연결을 설정하기 전 정보 교환이나 패킷이 잘 도착했는지 확인하는 기능 등을 규정한 프로토콜임. 처리 실패나 장애가 발생했을 때 오류 메시지를 통지하는 것이 주 역할임.

목적지에서 적절히 응답하는지 여부를 포함하여 데이터를 주고받을 때 필요한 전처리, 후처리, 관리 정보도 교환함. ICMP는 라우터나 스위치에 문의하여 라우터 간 제어 정보 교환이나 목적지가 있는지, 호스트가 작동하는지 등을 확인하는 다양한 목적으로 사용됨.

패킷은 ICMP 패킷의 헤더와 페이로드가 IP 패킷의 페이로드에 들어가는 형태로 구성됨(TCP/UDP와 동일). 헤더에는 타입, 코드, 체크섬을 지정하는 필드가 있음. 페이로드는 유형과 코드에 따라 다양하며, 오류 메시지와 전송 데이터(도착 여부)를 포함함. 헤더의 필드와 페이로드의 크기도 타입과 코드에 따라 다름.

타입: 패킷의 종류 (TCP, UDP, ICMP 등).
코드: 타입에 따라 내용이 다르지만, 주로 목적지 도달 불가(Destination Unreachable)의 원인을 나타내는 코드임.

46. telnet

텔넷은 단말기에서 서버에 원격으로 로그인하는 프로토콜임. 단말기와 서버가 텍스트 데이터를 주고받음. 서버에서 텔넷 서버 프로그램이 실행되고 있어야 하며, 단말기에서는 텔넷 클라이언트가 필요함. 23번 포트를 사용하고 ID와 암호로 서버에 로그인함.

⚠️ 문제점: 패킷을 암호화하는 기능이 없기 때문에 로그인 후 작업하는 명령 정보는 평문으로 네트워크로 전송됨. 이 때문에 현재는 SSH로 대체됨.

47. ssh

텔넷을 대신하여 원격 로그인에 사용하는 프로토콜임. 공개키 암호화 방식으로 공개키와 개인키를 사용하여 통신을 암호화하여 원격 접속을 보호함.

공개키 암호화

일반적인 암호화 방식은 양쪽이 같은 키를 공유하는 공통키 방식이지만, 공개키 암호화 방식은 공개키와 개인키라는 2개의 키를 사용함.

공개키 암호화 방식에서 두 키는 반드시 올바른 쌍으로 이용되어야 함. 공개키는 네트워크상에 공개하는 키로, 쌍이 되는 개인키가 없으면 복호화할 수 없음. 이는 전자 서명에도 사용하는 방식임.

SSH 암호화 원리

암호화 키를 생성하고 공유하는 방식에 따라 SSH1과 SSH2 두 가지 유형이 있음.

SSH1 (현재는 거의 사용 안 함)

클라이언트가 서버에서 받은 공개키로 암호화한 공통키(세션 키)를 생성하고, 그 암호화 데이터를 서버로 보냄. 서버는 그 데이터를 자신의 개인키로 복호화하여 공통키를 얻고, 이후 통신을 이 공통키로 암호화함.

[클라이언트]                                        [서버]
   |                                                   |
   | <----------- 1. 서버의 공개키 전송 <---------------- | (서버는 공개키와 개인키 보유)
   |                                                   |
   | 2. 세션에서 사용할 임시 '공통키' 생성                 |
   | 3. '공통키'를 서버의 '공개키'로 암호화              |
   |                                                   |
   | -------- 4. 암호화된 '공통키' 전송 ------------> |
   |                                                   |
   |                                                   | 5. 자신의 '개인키'로 복호화
   |                                                   |    -> '공통키' 획득
   |                                                   |
   | <============ 이후 모든 통신은 '공통키'로 암호화 ===========> |

SSH2 (현재 표준)

디피-헬만 키 교환 방식을 사용함. 양측이 각자 개인키와 공개키를 생성하고, 공개키만 서로 교환함. 그 후 각자 자신의 개인키와 상대방에게 받은 공개키를 조합하여 특수한 계산을 통해 동일한 통신용 공통키를 만들어냄. 이 방식은 중간에 공격자가 공개키를 탈취해도 개인키를 모르기 때문에 공통키를 계산할 수 없어 안전함. HTTPS의 암호화도 이 방식을 사용함.

[클라이언트]                                        [서버]
   |                                                   |
   | 1. 자신의 개인키(A)와 공개키(A) 생성              | 1. 자신의 개인키(B)와 공개키(B) 생성
   |                                                   |
   | <---------------- 2. 공개키(B) 교환 ----------------> |
   | <---------------- 2. 공개키(A) 교환 ----------------> |
   |                                                   |
   | 3. 자신의 개인키(A)와 서버의 공개키(B)로          | 3. 자신의 개인키(B)와 클라이언트의 공개키(A)로
   |    '공통키' 계산                                  |    '공통키' 계산
   |    (결과: K)                                      |    (결과: K)
   |                                                   |
   | <============ 이후 모든 통신은 '공통키(K)'로 암호화 =========> |

48. FTP

호스트 사이에서 또는 클라이언트와 서버 사이에서 파일을 주고받는 프로토콜임. 네트워크상의 저장소 등에 액세스할 때 사용함.

웹이나 파일 서버 등이 생기기 전부터 사용되어 왔음. 클라이언트가 FTP 서버에 로그인하면 서버에 있는 파일을 내려받거나 클라이언트의 파일을 업로드할 수 있음. 계정이 없어도 로그인할 수 있는 AnonymousFTP 서비스도 있음.

텔넷과 마찬가지로 로그인할 때 암호화가 되지 않으므로, 현재는 SCP나 SFTP처럼 암호화 통신이 가능한 프로토콜과 이를 지원하는 서버 또는 클라이언트 프로그램으로 대체되고 있음.

세션을 관리하는 **컨트롤 포트(21)**와 파일을 전송하는 **데이터 포트(20)**를 사용함. 데이터 포트는 원래 서버에서 파일을 전송하는 포트이며, 클라이언트와 파일 전송은 임의의 포트를 사용함. TCP 20번을 데이터 포트로 사용하는 모드를 액티브 모드라고 하며, 임의의 포트를 협상(negotiation)하는 모드를 패시브 모드라고 함. 포트를 나눈 것은 파일 전송 중에도 중단하는 등의 관리를 하기 위함임.

49. NTP

호스트 간에 시간을 동기화하는 프로토콜임. 서버가 내부에 시계를 가지고 있어 타임스탬프를 기록하거나 로그 파일의 시간 정보로 사용하는데, 시계는 오차가 있으므로 시간을 동기화해야 해서 사용하는 프로토콜임. NTP 서버는 클라이언트가 문의하면 현재 시간을 응답함. 각 국가에서 관리하는 표준 시계 정보를 이용함.

NTP 서버는 국가나 대학 등이 관리하는 표준 시간에 가까운 서버 아래 계층적으로 배치됨. Stratum 1 아래에 Stratum 2, 3 NTP 서버가 분기되어 연결되어 있음. 계층이 깊어지면 시간 오차가 누적되지만, Stratum 2 이하는 그 오차를 예측해서 보정함.

50. Ajax, REST API

Ajax

웹 서버는 브라우저의 요청에 대해 응답하기 전까지 다른 처리를 하지 않는데, 이를 동기 통신이라고 함. 대기 시간을 줄이기 위해 비동기 통신으로 추가 요청을 할 수 있도록 하는데, 이를 실현하기 위해서는 응답으로 주고받는 데이터 양을 줄여야 함. XML 형식으로 필요한 데이터만 주고받으며 비동기 통신을 할 수 있게 한 것이 **Ajax (Asynchronous JavaScript + XML)**임. 웹에서 지도를 스크롤하거나, SNS에서 타임라인을 표시하거나, 게임처럼 반응하는 웹페이지는 모두 Ajax로 구현된 것임.

REST API

애플리케이션 간 처리나 호출 방법 등을 정한 규약임. 보통 HTTPS를 사용하며, HTML이나 JSON, PHP 등으로 처리 내용이나 처리 데이터를 주고받음. 데이터베이스나 업무 시스템, 백엔드 시스템 등 기능을 호출할 때 사용함.